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EXPERIENCE. RESULTS. 


Introduction 

• Why modify FSW in flight? 

-Work around hardware problems on orbit 
-Correct software problems missed pre-launch 

- Enhance software capabilities during mission 

• Aspects of FSW design affecting maintainability 

-Resource margins 
-Linking: static v. dynamic 

- On-board file systems 

-Parameter setting: table-driven v. command driven 

• Methods for in-flight FSW modification 

• Case studies 




FSW Design: Resource Margins 

• Memory 

- Modified code = bigger code (usually) 

-GSFC Code 582 recommends at least 20% margin on memory 
that can be written in-flight 

• Telemetry 

-Modified code may add new telemetry 
-Need: 

• Spare space within packets 

• Capacity to add new packets 

• Bandwidth margin 
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FSW Design: Linking 

• Static Linking 

-Code built as absolute executable image 

- FSW component locations fixed by linker 

- No symbol table needed 

- Patch capability requires spare space in image 

- Flight memory image exactly duplicable on ETU 

• Dynamic linking 

-Application code built as relocatable module(s) 

-Module locations assigned by OS at runtime 
-Symbol table maps modules to locations 

- Flight memory image cannot be exactly duplicated on ETU 
-T radeoff: 

• Requires different maintenance approach 

• Offers potentially greater flexibility 





FSW Design: File Systems 

• To be really useful, file system (if there is one) should 
support: 

- File creation & deletion 

- File copy & move 

- Directory structure 

- Directory creation & deletion 




FSW Design: Parameters 

• Parameter setting via command is convenient 

• Parameter setting via table load supports configuration 
control 

• Tradeoff: operational convenience v. configuration control 






Methods for FSW Modification In-flight 

• Statically Linked Code 

-Inline Patch 

-Jump-Logic-Return Patch 
- Task Replacement 

• Dynamically Linked Code 

-Task Replacement 
-Adding a New Module 
-Function Replacement 

• Load New Image & Reboot 






Inline Patch 

• Overwrite one or a few words in executing RAM image 

• Can’t add new code 

-Change must fit within existing code 

• Feasible for: 

-Change to a hardcoded constant 
-Change to one or a few machine instructions 

• Caveat: Is the target instruction cached? 
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Jump-Logic-Return 

• Jump from existing code to new code, then return to 
existing code 

• Can be done at source code level (e.g. in C) by replacing a 
function 

- New function loaded to unused memory 

- Calls to old function patched inline to call new function 

• Requires free space built in to FSW image 



10/11/2007 8:45:21 AM 5864_ER_AERO 9 





Task Replacement (Static) 

• Halt task, load new version, restart task 

-Task must be designed to stop & restart cleanly (no memory 
leaks, broken pipes, etc.) 

-Task/fault management must permit task to stop & restart 

-Overwrite task in place 

• Requires each task have its own spare memory 

- Leave old task in place 

• Requires spare memory somewhere big enough to accommodate 
new task 

- If task can’t be restarted independently, FSW has to be 
rebooted 




Task Replacement (Dynamic) 

• Halt task, load new version, restart task 

- Uses OS task management & file system 

-Task must be designed to stop & restart cleanly (no memory 
leaks, broken pipes, etc.) 

-Task/fault management must permit task to stop & restart 
-Each task image should reside in its own file 

-File system should be flexible 

• Allow multiple versions of task files 

• Allow creation/deletion/concatenation of files 


Adding a Module 

• Some OS (e.g., VxWorks) can load a separate executable 
module 

• Module may not execute automatically when loaded 

-Can be spawned as a task from OS shell 
- Functions in module can be invoked from OS shell 

• Module’s global symbols (function names, global variables) 
added to OS symbol table when loaded 

• Module can access FSW globals via symbol table 
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Function Replacement 

• Achieve the effect of a jump-logic-return in a dynamically 
linked system 

• Function addresses not known a priori 

• Addresses must be obtained from symbol table 
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Load New Image & Reboot 

• May be necessary if FSW architecture precludes other 
methods 

• Uplink may take multiple passes over several days 

• Requires reboot of processor for changes to take effect 

• Reboot probably puts spacecraft in safehold 

- Disrupts normal mission ops 

- May pose risk to sensitive instruments 
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Case Study 1: Jump-Logic-Return 

Adding an In-Flight Timing Diagnostic on Space Technology 5 

• Digital Sun Sensors (DSS) on ST5 reported multiple 
spurious sun pulses 

• Accurate diagnosis required precise timing data on DSS 
ISR task execution 

• All FSW tasks had calls to timing diagnostic output functions 
used during development 

• Patch added a new function to accumulate timing data for 
subsequent dump to ground 

• Existing diagnostic output functions patched to call new 
function 

• Code is written in C and is statically linked 
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Case Study 1: Jump-Logic-Return 
Memory Map of ST5 FSW Image 


Start Address 

End Address 

Description 

Size 

0x80020000 

0x801 749CF 

OS & FSW 
Code 

1.3 MB 

0x801 749D0 

0x801 FFFFF 

Spare Space 

557 kB 

0x80200000 

0x802 D3AEB 

Initialized & 
Uninitialized 
FSW Data 

846 kB 

0x802 D3AEC 

0x806FFFFF 

Spare Space 

4.2 MB 

0x80700000 

0x807439D3 

OS Kernel 
Code & Data 

270 kB 

0x807439D4 

0x807FFFFF 

Free Memory 
Pool 

750 kB 
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Case Study 1 : Jump-Logic-Return 
As-Launched Source Code for Timing Diagnostics 

void OSPerfLog_entry(u_dword id) 


OS_write_io_word(id, 1); 

} 

void OSPerfLog_exit(u_dword id) 
OS_write_io_word(id, 0); 

} 
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Case Study 1 : Jump-Logic-Return 
As-Launched Disassembly for Timing Diagnostics 


ffffffff8016fc88: 

24050001 

li 

$a1,1 

ffffffff8016fc8c: 

0c05c3f4 

jal 

80170fd0 

<ClockRate+0x7f5ff4d0> 


ffffffff8016fc90: 

00000000 

nop 


ffffffff8016fcc4: 

00002821 

move 

$a1 ,$zero 

ffffffff8016fcc8: 

0c05c3f4 

jal 

80170fd0 

<ClockRate+0x7f5ff4d0> 


ffffffff8016fccc: 

00000000 

nop 
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Case Study 1 : Jump-Logic-Return 
Modified Source Code for Timing Diagnostics 

void OSPerfLog_entry(u_dword id) 

{ 

OSPerfLog_add(id, 1); 

} 

void OSPerfLog_exit(u_dword id) 

{ 

OSPerfLog_add(id, 0); 

} 
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Case Study 1: Jump-Logic-Return 
Modified Disassembly for Timing Diagnostics 


ffffffff8016fc88: 

24050001 

li 

$a1,1 

ffffffff8016fc8c: 

OcOcOOOO 

jal 

80300000 

<ClockRate+0x7f78e500> 


ffffffff8016fc90: 

00000000 

nop 


ffffffff8016fcc4: 

00002821 

move 

$a1,$zero 

ffffffff8016fcc8: 

OcOcOOOO 

jal 

80300000 

<ClockRate+0x7f78e500> 



ffffffff8016fccc: 

00000000 

nop 
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Case Study 2: Task Replacement 

Figure of Merit (FOM) task on Swift/Burst Alert Telescope 
(BAT) 


• Dynamically linked code modules with flexible file system 

• Uplink steps 

-Break new FOM task object into multiple files 
— Uplink files over several passes 

- Concatenate files into one task object file 
-Stop old FOM task 

- Load new FOM task to RAM from object file 
-Start new FOM task 

• On-board startup script modified to start new FOM task in 
event of reboot 

• Old FOM task still present as object file 



-Can be used if new FOM task fails 
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Case Study 3: Patching Dynamically Linked Code 

• A proof-of-concept experiment using Swift/BAT FSW lab 

• Uses symbol table features of VxWorks 

• Test function: 

#include "dummyfunc.h" 

void rundummyO 

{ 

dummyfunc(); 

} 
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Case Study 3: Patching Dynamically Linked Code 

#include <stdio.h> 

#include "dummyfunc.h" 
int myvalue=1984; 

void dummyfunc() { 

sy_shellStream->write( M l am a C function dummyfuncW); 
sy_shellStream->write("myvalue is: %d\n", myvalue); 

} 

#include <stdio.h> 

#include "dummyfunc.h" 

void dummyfunc2() { 

sy_shellStream->write("l am another C function dummyfunc2\n"); 
sy_shellStream->write("myvalue=%d\n", myvalue); 

} 
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Case Study 3: Patching Dynamically Linked Code 

• Fragments from function patchitl (): 

• Declarations 

#define BL_MASK 0x48000001 
#define SX_MASK 0x03FFFFFF 

char *dummyfunc_name = "dummyfunc Fv"; 

char *dummyfunc2_name = "dummyfunc2 Fv"; 

char *call_function_name = "rundummy Fv"; 

char *whereis_dummyfunc = NULL; 
char *whereis_dummyfunc2 = NULL; 
char *whereis_target = NULL; 
char *whereis_call_function = NULL; 
unsigned long int branch_to_old; 
unsigned long int branch_to_new; 
unsigned long int target_offset = OxOOOC; 
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Case Study 3: Patching Dynamically Linked Code 

• Get function addresses 

symFindByName(sysSymTbl, dummyfunc_name, 
&whereis_dummyfunc, &dummyfunc_symtype); 

symFindByName(sysSymTbl, dummyfunc2_name, 
&whereis_dummyfunc2, &dummyfunc2_symtype); 

symFindByName(sysSymTbl, call_function_name, 
&whereis_call_function, &call_function_symtype); 






Case Study 3: Patching Dynamically Linked Code 

• Test Results: 

• Load all functions 

Id <targ/nram/temp/dummyf1 .o 

value = 7326896 = 0x6fccb0 = myvalue + 0x3cc 

Id <targ/nram/temp/dummyf2.o 

value = 7337136 = 0x6ff4b0 = dummyfunc2(void) + 0x4ac 

Id <targ/nram/temp/rundummy.o 

value = 7336480 = 0x6ff220 = rundummy(void) + Oxfc 

Id <targ/nram/temp/patchit1 .o 

value = 7332528 = 0x6fe2b0 = patchitl(void) + 0x8bc 


Case Study 3: Patching Dynamically Linked Code 

• First execution of rundummy 
rundummyO 

I am a C function dummyfuncl 
myvalue is: 1 984 
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Summary 

• Maintainability should be considered in FSW design 

- Margin on system resources 
-Spare memory in a static FSW image 
-Task modularity in a dynamic FSW system 

- Flexibility of file system 




